Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.05%. Comparing base (0fe5e6c) to head (d257492).

@@            Coverage Diff             @@
##             main     #485      +/-   ##
==========================================
+ Coverage   97.01%   97.05%   +0.04%     
==========================================
  Files          20       20              
  Lines        3950     4005      +55     
==========================================
+ Hits         3832     3887      +55     
  Misses        118      118              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Therefore, I'd like to be able to make rustls-webpki ignore these extensions when building a path, and verify these later separately.

An earlier discussion on this: #232 (comment)

Thanks for linking this, I have not seen this.

I think my approach matches the spirit of this comment moderately well:

looks like they record all extensions, plus a set of extension OIDs that were critical but not recognised by the core library. then chain verification fails if the unhandled-but-critical set is non-empty. but that means callers can potentially act on those extensions, delete them from the unhandled set, and then do verification afterwards?

In my approach, the user still needs to explicitly declare which critical extensions are to be ignored, and is free to do any processing before or after. The user will need to reparse the certificate to extract the extensions, but I think this is unavoidable in any case: rustls-webpki cannot offer much help in parsing the extensions it does not recognize.

At best, I guess what rustls-webpki could offer is an additional method on Cert:

impl Cert<'a> {
   pub fn extensions(&self) -> impl Iterator<Item = &[u8]>
}

that just iterates over the DER bytes of extensions.

We could actually go one step further, and introduce a public API for extension that just matches the RFC 5280 definition:

struct Extension<'a> { ... }

impl Extension<'a> { 
  pub fn oid(&self) -> &[u8] { ... }
  pub fn is_critical(&self) -> bool { ... }
  pub fn value(&self) -> &[u8] { ... }
}

and have the Cert::extensions return an Iterator over that. Would you like me to implement that?

Hey, I rebased the branch to use the new PathBuilder API. Please take a look.

An X.509 certificate with critical extensions that uses "private critical extensions" is not a WebPKI certificate so it is out of scope of this library.

If there is interest in supporting non-WebPKI-conformant certificates then I think it would be good if the API for that made a clear distinction between WebPKI certificate processing and non-WebPKI certificate processing. There are definitely a lot of certificate hierarchies that aren't too different from the WebPKI where this library almost works for them, so it is tempting to add features to support this.

The idea I've been kicking around is to have a trait Extensions and replace extensions fields in Cert with a T: Extensions, which should have some methods for a minimal set of extensions that we need to build a verified path. That way (a) we can keep doing our thing and (b) we offer an extension point that people who want to go off the web PKI path can more easily customize.

Even still, I think it would be good to have more of a distinction in the API between "Hey, I'm using this to validate a WebPKI certificate" vs. other certificates. The recent addition of things like the RequiredXIfYPresent EKU policy stuff already have started to make it difficult to see what parts of this code are relevant to the WebPKi and which aren't.

With respect to this potential API, I think we should also enforce that the ignored critical extensions are NOT standardized extensions. e.g. don't let this API be used to ignore policy-related extensions or other WebPKI-relevant extensions. Otherwise, we encourage people to build applications that are incompatible with more fully-featured standard WebPKI-compatible libraries. One potential way to do this would be to validate that the extensions to ignore have OIDs that aren't in standardized OID namespaces.

The main footgun in APIs like this, which let the application process extensions themselves, is that now that extension processing doesn't influence path building. This is most likely to happen when the extensions are in CA certificates. I suggest that any such API accept separate sets of extensions for end-entity and CA certificates. In the case of the OP's issue, based on the original summary, it seems likely that those extensions are in end-entity certificates?

I think people use rustls-webpki for all kind of certificate validation, not just the WebPKI profile, because there simply aren't any pure Rust alternatives that are nearly as solid. The only other realistic option is to use OpenSSL bindings, or an OpenSSL derived library like AWS LC.

There would be value in implementing path building API which mirrors closely the algorithm described in RFC 5280, including the specified inputs, and hooks into each step. Many extensions describe their processing in terms of how to modify the RFC 5280 algorithm.

See, for example, RFC 5937, Using Trust Anchor Constraints during Certification Path Processing: it tells you how to modify the inputs to the RFC 5280 algorithm, but then doesn't require any special processing during building, because the modification to the inputs will affect how the standard algorithm operates. Doing this is impossible with current rustls-webpki API, which deliberately forgets all the information on the trust anchors except the data that's actually needed.

With respect to this potential API, I think we should also enforce that the ignored critical extensions are NOT standardized extensions. e.g. don't let this API be used to ignore policy-related extensions or other WebPKI-relevant extensions.

My change does not disable processing of the critical extensions that are part of WebPKI, and in fact I added a test for it: ignored_critical_extensions_do_not_disable_supported_extension_parsing

I suggest that any such API accept separate sets of extensions for end-entity and CA certificates.

My change does exactly that, compare ignored_critical_extension_on_end_entity vs. ignored_critical_extension_on_end_entity, although I did not exactly intend it to be that way, it just ended up being forced by the existing API, which required parsing the EndEntityCert before calling verify_for_usage, but did not parse the intermediates until it actually needs them in the process of path building.

In the case of the OP's issue, based on the original summary, it seems likely that those extensions are in end-entity certificates?

I actually struggle with two distinct kinds of private extensions, believe it or not. Once is on end-entity only, and the other affects the entire path.

I will give you an example of a public extensions, however. Consider the processing procedure described in RFC 5913. It plays absolutely no role during actual path building (at least so far as I understand it), and can be applied separately to the finished verified path.